P1111.BUGS Oh heck, there are always bugs. I can run my own programs for years and never see a bug, but give it to someone else and XAPPO! Many of these have been fixed, some are not really bugs, others are not caused by program. 1. There is a bug where the TNC reconnects to the other station after the other station disconnects. This can happen when there is data left in the TNC buffer after the disconnect, and it seems the TNC reconnects so that it can complete the transmission. KA2BQE says this is a bug in the AX25L2V2 protocal and that the NETROM writers saw this and invented their own protocol. Never been able to duplicate the reconnect when AX25L2V2 was turned off, so he may be correct. 2. FULL-DUPLEX TNC operation. This is when your TNC starts transmitting, and you know by listening to the packets that it should be receiving. On the Kantronics KAM, I found this happened when MAXUSERS or (USERS?) was set to 0/1. Didn't care if FULLDUP parameter was on or off. 3. Header time changes EST to UTC. Re-assemble to change. Argh! 4. The garbage on the screen when a station disconnects. OK, the disconnect sequence has been the real tuffy on this BBS thing. I am still studying all the numerous ways a disconnect can screw up, and the junk is the only way I can watch what happens. Most of it will be eliminated at some future revision. 5. When used as a terminal on packet, in the monitor mode (F5 toggled on) I keep thinking that it misses the first line of a message on occasions. Must have looked for this bug 20 times, and keep drawing a blank. Me thinks that this bug doesn't exist. 6. New message overwrites older message. Happens when you delete a message from the top of the DIR. The BBS looks at the first 4 bytes of DIR and uses that number as the last message number used, adds 1 to it and writes the next message under this new number. Can't see an easy way around this, the answer for now is to not delete the top entry in DIR. 7. Kantronics PBBS forward. Not a bug because this works, both on older and newer Kantronics PBBS's. This BBS sends SP WA3MNT < N3ET @ BBS and this format works, but is not the 'standard' for forwarding (assuming there is a 'standard'). 8. PRMBS (a la KA2BQE). Forwarding works, but you never know what BQE is gonna do on his next PRMBS revision. Forwarding may look strange at times when TO or FROM a PRMBS, but I've never seen a forward fail. 9. *** ERRORS. This BBS will tend to disconnect when it sees an ERROR message. Well, better this then carry on for hours sending WHAT, HUH, or INVALID COMMAND. Also, there may be a case where this BBS sends a *** ERROR message, then sends a prompt '>'. Still watching for this. The prompt may cause the other end to think a message was properly forwarded. 10. F9 BBS disable. There may be a problem if you have the BBS disabled and someone connects and the terminal part times out, causing the BBS to be enabled for the next connect. I gotta see if I can force this. 11. HELP-KEY - Press this a second time before first completes, lose stack. 12. NETROM. If you connect to EPA, then tell EPA NETROM to connect to KB3UD, you think you are connected to KB3UD. No. You are connected to EPA, not KB3UD. BBS picks up on correct call from NET/ROM, TheNet, and KA-NODES and works OK. 13. NETROM. Set your FRACK and DWAIT a little higher if you get too many collisions with AX25L2V2 polls. 14. MESSAGE disconnects. Someone starts a message and disconnects. If no text has been entered, the BBS looks dead. Give it 256 seconds ~4 minutes to time out. 15. MESSAGE too big. This BBS has a safety switch that stops saving a messsage after 65k. You will have no indication of this. The counters and all are capable of many gigabytes, but my computer isn't. 16. CAPTURE too big. The terminal part has a safety switch thats stops capturing after 1.8 megabytes (+/-). Seemed a good number for my 3 megabyte RAM. I think this was deleted ?? 17. MESSAGE forward. A lot of TNC STATUS lines go to the screen when the BBS forwards a message. The BBS looks for # (busy) C (connected to) D (Disconnected) etc. Again, this is useful debug info. 18. #ELK connection. The TNC won't allow this (C #ELK). 19. RM returns with error when no message for you. 20. *** DISK FULL. Another PRMBS special. I think this BBS will disconnect when it sees this message. If it don't, then it is a bug. 21. SP WA3MNT N3ET. BBS will not recognize N3ET, nor report the error. 22. CMD: HUH eh?. You may get 50 of these in a row. Happens when someone tries to connect and doesn't copy you. BBS retries out, sees another connect, and gets confused. Takes a while, but BBS should recover. 23. USR file corrupted. Usually drops everything but call, then gets wrong name on next user. I've had this happen after pushing PANIC BUTTON, F10, when BBS was active. Also happens with disk errors or messed up B:USR. 24. DIR file corrupted. Only saw this happen when SYSOP faked an entry without correct number of spaces. If you get lost, have another BBS or person send you a message like SP WA3MNT @ KA3JAI < WB3HVJ then look at what the BBS did in the DIR. 25. B:BID sometimes messes itself. New B:BID with old pointer. Fixed?? 26. LIST NONE. If nothing to list, 'L' command just prompts. 27. Amiga DIR command. You get a GURU if you use DIR RAM: OPT I and then type 'T' on a file that BBS is writing to. 28. NO MEMORY. Gimme a break, if you run out of memory or DISK space, the AMiga should (will) tell you about it. I don't know how to handle this cause I never let it happen. 29. STACK 8000. BBS really needs about 1000 byte stack or less. I run with STACK 8000 in my S/Startup-Sequence file. 30 ICONS. I don't. So the BBS don't either. Sorry, but you rodent fans hafta learn CLI. Read this => you can't use the MOUSE to run the BBS from WORKBENCH.